今天來了解一下 Unit Test 的基本概念，我會分成幾個部分：
先來看看我們一般的開發流程：
那再來看一下 Unit Test 的大概流程，這裡先以 TDD 精神為例：(之後篇章會學到 TDD)
看出來差別了？
從剛剛的結論可以得知，撰寫測試會額外增加開發時間，而且還是老闆看不到的那種。
那來看看 Unit Test 可以解決什麼問題，看看能不能讓寫 Unit Test 時間成本花的更值得？
降低後續維護專案的成本：
Unit Test 會在開發過程中留下紀錄，可以讓其他開發人員(或者未來的你)在協作開發或維護可以更快進入狀況，而且留下測試工具讓夥伴可以直接進行驗證。
小範圍進行驗證，升級我們的程式碼品質：
Unit Test(單元測試)：顧名思義就是將專案中的功能切分成小單元，像是function 進行測試，讓我們開發時更容易聚焦處理小範圍的邏輯是否符合預期。
同時，為了達到小範圍測試，也會影響我們撰寫程式的習慣，我們會更傾向寫出更簡潔、模組化的程式碼(當然，過程中會有重構的陣痛期)。
提高開發時期偵錯能力，降低協作夥伴踩雷 或 專案上線出問題的機率：
在多人協作的專案中，每一次 commit 前跑過一次測試，可以確保每次 commit 不會搞爛專案，減省為了賠罪請專案同事下午茶的錢。
或者，專案上線後，突然有一天水逆，有一堆來自不同部門的人來電說「這個怎麼壞了！」「我剛剛資料打超久都沒了，浪費我時間！」「什麼時候可以修好，我今天要交給廠商欸！」讓你的人生直接黑白的體驗。
可以搭配自動化測試工具，簡化除錯的流程(時間成本)
看來寫 Unit Test 初期要努力一點，後面掃雷的機率會大幅降低，可以讓自己在公司成為好人緣代表，也會讓自己養成更好的撰寫習慣，你看看你覺得值得嗎？
從今天入門的Unit Test概念學習，我可以預見在實務工作上使用Unit Test最大的挑戰：
當我們專案中實行MVP(Minimum Viable Product) 衝刺計畫時，第一點與第二點顯而易見，這是我們必須不斷遭遇的挑戰。更甚者，所有參與專案的協作夥伴都必須嚴守 Unit Test 準則，才有辦法讓測試精神發揮最大效用。
因為，只要中途有人放棄更新 Unit Test，測試程式碼就會變成垃圾。未來如果我要維護一項專案，一旦發現測試功能與現有專案不符，我會直接假設專案內所有測試程式碼都沒有長期維護，一樣把他冷凍處理，這時候專案內存在的測試程式碼就會變成包袱。
但即使如此，我還是認為學習 Unit Test 有他的價值，因為所以技術的出現都是為了解決遇到的問題，所以現在我預見的隱憂，一定有其他套件或方式可以讓測試工具更佳方便、更佳好管理，提高開發者使用的意願。搞不好早就有解決方法，只是我初入火坑所以還沒發現而已！
iThome鐵人賽
看影片追技術